Application performance management relates to technologies and systems for monitoring and managing the performance of applications. For example, application performance management is commonly used to monitor and manage transactions performed by an application running on a server to a client.
Today, many applications can be accessed over a network, such as the Internet or intranet. For example, due to the ubiquity of web browsers on most client devices, web applications have become particularly popular. Web applications typically employ a browser-supported infrastructure, such as Java or a .NET framework. However, the performance of these types of applications is difficult to monitor and manage because of the complexity of the software and hardware and numerous components that may be involved.
A transaction typically comprises a sequence of method calls in a program that represent a complete set of operations necessary to perform a self-contained unit of work, such as a web request or a database query. Transactions can be traced to monitor and manage their performance. For example, a trace can be performed in an application server to obtain detailed information about the execution of an application within that server.
Unfortunately, the tracing of a transaction through a typical network system is difficult. For example, even when several network-connected interoperating components of a multi-tier application are all instrumented, the known application monitoring systems and methods are unable to correlate transaction call sequences from those components that are causally related. These communications are difficult to correlate because they are independently running on the client and server. In addition, the common use of network address translation makes tracing these communications difficult.
In some known systems, for hypertext transport protocol (HTTP) based requests, it is possible to insert a unique custom header on the client side into an outgoing HTTP request message, and to intercept this custom header on the server side. If each side of the transaction (i.e., the client and server) is tracing calls, the custom header associated with the HTTP request can be recorded to the trace files on each side of each request and response. The associated calls can later be correlated based on this custom information.
Unfortunately, for cross-tier communications that are not encapsulated as HTTP requests and responses, it is generally not possible to insert such additional context into the messages.
Furthermore, in a traditional transaction trace for web applications, Java or .NET instrumentation components are running (on the application server, the client, etc.) and write records of all of the method calls of a transaction to a transaction trace file. Such tracing must be predominantly initiated manually or triggered by a program condition and for only a limited period of time. It is necessary to limit trace duration and detail in the conventional systems because the act of tracing is relatively expensive and could negatively system performance and disk space of the server, the client, etc.
Accordingly, this also means that in many circumstances the execution of an application within a system cannot be diagnosed or monitored regardless of whether the communications are HTTP based or not.
Throughout the drawings, the same reference numerals indicate similar or corresponding features or functions. The drawings are included for illustrative purposes and are not intended to limit the scope of the invention.